An UMTS terrestrial radio access network (hereinafter, referred to as “UTRAN”) of a third generation mobile communication system is made up of a plurality of radio network subsystems (hereinafter, referred to as “RNS”). Here, one RNS has a plurality of node Bs and radio network controllers (hereinafter, referred to as “RNC”).
The node B connects a user equipment (hereinafter, referred to as “UE”) to the UTRAN.
The RNC performs assignment and management of radio resource for each of the UEs.
The UE is connected to a core network (hereinafter, referred to as “CN”) such as a mobile switching center or a SGSN through the RNC.
To set shortly connection path between the UE and the CN in response to moving of the UE, a RNC for the UE is shifted from a source RNC in present SRNS into a target RNC in another SRNS. This is referred to as an SRNS relocation.
The SRNS relocation is generally performed so that data are not lost, and so an acknowledged mode AM RLC entity of a user plane or a control plane is used in the SRNS assignment.
In the SRNS relocation, the source RNC transmits information concerning unidentified data to the target RNC through a down-link or provides serial number corresponding to the data through an up-link.
In case that the target RNC receives the information or the serial number, the SRNS relocation is performed between the target RNC and the UE. Here, the SRNS relocation is started through an UTRAN mobility information UMI message or a radio bearer reconfiguration RBR message defined by a 3GPP in accordance with a network mode.
However, a problem exists in that call drop may be occurred in case that RLC reset is performed or other exceptional case is occurred while the UMI message or the RBR message is delivered in the SRNS relocation.
FIG. 1 and FIG. 2 are views illustrating examples of call drop in conventional SRNS relocation. Particularly, FIG. 1 and FIG. 2 show call drop in an UMI procedure.
Referring to FIG. 1, in step S100, in case that the source RNC transmits information concerning unidentified data, etc. to the target RNC, the UMI procedure is started.
In step S102, a radio resource control RRC entity of the target RNC transmits an UMI message to a RRC entity of the UE.
In step S104, the RRC entity and a radio link control RLC entity of the UE perform a RLC configuration procedure.
In step S106, the RRC entity of the UE transmits an UMI confirm UMIC message to the RRC entity of the target RNC after the RLC configuration procedure is performed. Here, the SRNS relocation is normally completed only when the RLC entity of the UE receives ACK about the UMIC message from the RLC entity of the target RNC. For example, the RRC entity of the UE resets the RLC entity in accordance with the RLC configuration procedure, and then transmits the UMIC message having initial serial number SN0 to the RRC entity of the target RNC. Hence, the SRNS relocation is normally completed only when the RLC entity of the target RNC transmits the ACK (about the UMIC message) having next serial number to the RLC entity of the UE.
However, in case that the RLC entity of the target RNC transmits ACK having other serial number, e.g. SN9 not desired serial number SN1 to the RLC entity of the UE due to information concerning serial number provided from the source RNC to the target RLC in step S108, the RRC entity of the UE discriminates that the RLC entity of the UE does not receive normally the ACK about the UMIC message, and so the RRC entity of the UE performs a RRC disconnect procedure in step S110. As a result, call drop is occurred in step S112.
Hereinafter, another example of call drop will be described in detail with reference to accompanying drawing FIG. 2.
Steps S200 to S206 in FIG. 2, i.e. step of transmitting the UMI message from the target RNC, step of performing the RLC configuration and step of receiving the UMIC message are the same as those in FIG. 1.
Referring to FIG. 2, the target RNC awaits ACK (which is transmitted to the source RNC if the SRNC reassignment is not started) transmitted from the UE according as the target RNC receives the information concerning the unidentified data from the source RNC. Here, the target RNC should receive the ACK having serial number following serial number of the unidentified data. However, the RLC entity of the target RNC does not receive ACK having desired serial number due to performance of the RLC configuration procedure. As a result, the RLC entity of the target RNC transmits a RLC RESET message to the RLC entity of the UE in step S208.
In step S210, the RRC entity of the UE discriminates through the transmitted RLC RESET message that the RLC entity of the UE does not receive desired ACK, and performs a RRC disconnect procedure. Then, the UMI procedure is finished in step S212.
FIG. 3 and FIG. 4 are views illustrating another example of call drop. Particularly, FIG. 3 and FIG. 4 show call drop occurred when a RBR message or a RBRC message is delivered in accordance with a certain network mode in the SRNS relocation.
Referring to FIG. 3, in step S300, in case that the source RNC transmits information concerning the unidentified data, etc. to a target RNC, a RBR procedure is started.
In step S302, the RRC entity of the target RNC transmits a RBR message to the RRC entity of an UE.
In step S304, the RRC entity and the RLC entity of the UE perform an RLC configuration procedure.
In step S306, the RRC entity of the UE transmits a RBR complete RBRC message to the RRC entity of the target RNC after the RLC configuration procedure is performed. Here, the RRC entity of the UE resets the RLC entity in accordance with the RLC configuration procedure, and then transmits the RBRC message having an initial serial number SN0 to the target RNC.
On the other hand, the RBR procedure is normally completed only when the RLC entity of the UE receives ACK about the RBRC message from the RLC entity of the target RNC. For example, in case that the RBRC message having the serial number SN0 is transmitted, the SRNS assignment is normally completed only when the RLC entity of the UE receives the ACK (about the RBRC message) having next serial number from the RLC entity of the target RNC.
However, in case that the RLC entity of the target RNC transmits ACK having other serial number, e.g. SN32 not desired serial number SN1 to the RLC entity of the UE due to information concerning serial number provided from the source RNC to the target RLC in step S308, the RRC entity of the UE discriminates that the RLC entity of the UE does not receive desired ACK about the RBRC message, and so the RRC entity of the UE performs a RRC disconnect procedure in step S310. That is, the RRC disconnect procedure is performed because the serial number of the received ACK is not identical to desired serial number. As a result, the RBR procedure is failed, and thus call drop is occurred in step S312.
The above call drop may be occurred when serial number of the received ACK is not existed in an effective range.
FIG. 4 is a view illustrating still another example of call drop.
Steps S400 to S406 in FIG. 4, i.e. step of transmitting the RBR message from the target RNC, step of performing the RLC configuration and step of receiving the RBRC message are the same as those in FIG. 3.
Referring to FIG. 4, the target RNC awaits ACK (which is transmitted to the source RNC if the SRNC reassignment is not started) transmitted from the UE according as the target RNC receives the information concerning the unidentified data from the source RNC. Here, the target RNC should receive ACK having serial number following serial number the data transmitted from the source RNC. However, the RLC entity of the target RNC does not receive ACK having desired serial number due to performance of the RLC configuration procedure. As a result, the RLC entity of the target RNC transmits a RLC RESET message to the RLC entity of the UE in step S408.
In step S410, the RRC entity of the UE discriminates through the transmitted RLC RESET message that the RLC entity of the UE does not receive normally desired ACK, and performs a RRC disconnect procedure. Then, the RBR procedure is finished as fail state in step S412.
3GPP defines generally the SRNS relocation as to only case that a given message is normally delivered between the target RNC and the UE. However, the 3GPP does not define the SRNS relocation as to case that serial numbers delivered between the target RNC and the UE are not identical, or case that the target RNC and the UE do not receive a given message, e.g. ACK because a process between the UE and the source RNC is not finished.
In brief, the 3GPP does not define a method of processing the above exceptional cases when the exceptional cases are occurred between the target RNC and the UE. Accordingly, a problem exists in that the call drop is unconditionally performed whenever the exceptional cases are occurred.